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Abstract 


This document specifies the behavioral properties required of the 
Network Address Translator (NAT) devices in conjunction with the 
Internet Control Message Protocol (ICMP). The objective of this memo 
is to make NAT devices more predictable and compatible with diverse 
application protocols that traverse the devices. Companion documents 
provide behavioral recommendations specific to TCP, UDP, and other 
protocols. 
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Iz 


Introduction and Scope 


As pointed out in RFC 3424 [UNSAF], NAT implementations vary widely 
in terms of how they handle different traffic. The purpose of this 
document is to define a specific set of requirements for NAT behavior 
with regard to ICMP messages. The objective is to reduce the 
unpredictability and brittleness the NAT devices (NATs) introduce. 
This document is an adjunct to [BEH-UDP], [BEH-TCP], and other 
protocol-specific BEHAVE document (s) in the future that define 
requirements for NATs when handling protocol-specific traffic. 


The requirements of this specification apply to traditional NATs as 
described in [NAT-TRAD]. A traditional NAT has two variations, 
namely Basic NAT and Network Address Port Translator (NAPT). Of 
these, NAPT is by far the most commonly deployed NAT device. NAPT 
allows multiple private hosts to share a single public IP address 
simultaneously. 


This document only covers the ICMP aspects of NAT traversal, 
specifically the traversal of ICMP Query messages and ICMP Error 
messages. Traditional NAT inherently mandates firewall-like 
filtering behavior [BEH-UDP]. However, firewall functionality in 
general or any other middlebox functionality is out of the scope of 
this document. 


In some cases, ICMP message traversal behavior on a NAT device may be 
overridden by local administrative policies. Some administrators may 
choose to entirely prohibit forwarding of ICMP Error messages across 
a NAT device. Some others may choose to prohibit ICMP-Query-based 
applications across a NAT device. These are local policies and not 
within the scope of this document. For this reason, some of the ICMP 
requirements listed in the document are preceded with a constraint of 
local policy permitting. 


This document focuses strictly on the behavior of the NAT device, and 
not on the behavior of applications that traverse NATs. Application 
designers may refer to [BEH-APP] and [ICE] for recommendations and 
guidelines on how to make applications work robustly over NATs that 
follow the requirements specified here and the adjunct protocol- 
Specific BEHAVE documents. 


Per [RFC1812], ICMP is a control protocol that is considered to be an 
integral part of IP, although it is architecturally layered upon IP 
-- it uses IP to carry its data end-to-end. As such, many of the 
ICMP behavioral requirements discussed in this document apply to all 
IP protocols. 
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In case a requirement in this document conflicts with protocol- 
specific BEHAVE requirement (s), protocol-specific BEHAVE documents 
will take precedence. The authors are not aware of any conflicts 
between this and any other IETF document at the time of this writing. 


Section 2 describes the terminology used throughout the document. 
Section 3 is focused on requirements concerning ICMP-Query-based 
applications traversing a NAT device. Sections 4 and 5 describe 
requirements concerning ICMP Error messages traversing a NAT device. 
Sections 6 describes requirements concerning ICMP Error messages 
generated by a NAT device. Section 7 reviews RFC 1812 conformance 
requirements and applicability to NATs when handling ICMP messages. 
Section 8 reviews a requirement for ICMP messages that are neither 
ICMP Query nor ICMP Error kind. Section 9 summarizes all the 
requirements in one place. Section 10 has a discussion on security 
considerations. 


2. Terminology 


Definitions for the majority of the NAT terms used throughout the 
document may be found in [NAT-TERM] and [BEH-UDP]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The term "Realm" is adapted from [NAT-TERM] and is defined as 
follows. "Realm" is often interchanged for "network domain" or 
simply "network" throughout the document. 


Address realm or Realm - An address realm is a network domain in 
which the network addresses are uniquely assigned to entities such 
that datagrams can be routed to them. Routing protocols used within 
the network domain are responsible for finding routes to entities 
given their network addresses. Note that this document is limited to 
describing NAT in the IPv4 environment and does not address the use 
of NAT in other types of environments (e.g., the IPV6 environment). 


The term "NAT Session" is adapted from [NAT-MIB] and is defined as 
follows: 


NAT Session - A NAT session is an association between a session as 
Seen in the private realm and a session as seen in the public realm, 
by virtue of NAT translation. If a session in the private realm were 
to be represented as (PrivateSrcAddr, PrivateDstAddr, 
TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same 
session in the public realm were to be represented as (PublicSrcAddr, 
PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the 
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NAT session would provide the translation glue between the two 
session representations. NAT sessions in the document are restricted 
to sessions based on TCP, UDP, and ICMP. In the future, NAT sessions 
may be extended to be based on other transport protocols such as 
Stream Control Transmission Protocol (SCTP), UDP-lite, and Datagram 
Congestion Control Protocol (DCCP). 


ICMP Message Classification - Section 3.2.2 of [RFC1122] and Section 
4.3.1 of [RFC1812] broadly group ICMP messages into two main 
categories, namely "ICMP Query" messages and "ICMP Error" messages. 
All ICMP Error messages listed in RFC 1122 and RFC 1812 contain part 
of the Internet datagram that elicited the ICMP error. All the ICMP 
Query messages listed in RFC 1122 and RFC 1812 contain an 
"Identifier" field, which is referred to in this document as the 


"Query Identifier". There are however ICMP messages that do not fall 
into either of these two categories. We refer to them as "Non- 
QueryError ICMP Messages". All three ICMP message classes are 


described as follows: 


o ICMP Query Messages - ICMP Query messages are characterized by an 
Identifier field in the ICMP header. The Identifier field used by 
the ICMP Query messages is also referred to as "Query Identifier" 
or "Query Id", for short throughout the document. A Query Id is 
used by Query senders and responders as the equivalent of a TCP/UDP 
port to identify an ICMP Query session. ICMP Query messages 
include ICMP messages defined after RFC 1122 or RFC 1812 (for 
example, Domain Name Request/Reply ICMP messages defined in RFC 
1788), as they include request/response pairs and contain an 
"Identifier" field. 


o ICMP Error Messages - ICMP Error messages provide signaling for IP. 
All ICMP Error messages are characterized by the fact that they 
embed the original datagram that triggered the ICMP Error message. 
The original datagram embedded within the ICMP Error payload is 
also referred to as the "Embedded packet" throughout the document. 
Unlike ICMP Query messages, ICMP Error messages do not have a Query 
Id in the ICMP header. 


o Non-QueryError ICMP Messages - ICMP messages that do not fall under 
either of the above two classes are referred to as "Non-QueryError 
ICMP Messages" throughout the document. For example, Router 
Discovery ICMP messages [RFC1256] are "request/response" type ICMP 
messages. However, they are not characterized as ICMP Query 
messages in this document as they do not have an "Identifier" field 
within the messages. Likewise, there are other ICMP messages 
defined in [RFC4065] that do not fall in either of the ICMP Query 
or ICMP Error message categories, but will be referred to as Non- 
QueryError ICMP messages. 
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The reason for categorizing ICMP messages for NAT behavioral 
properties is that each category has different characteristics used 
for mapping (i.e., the Query Id and the Embedded datagram), which 
leaves the Non-QueryError ICMP messages in a separate, distinctive 
group. 


3. ICMP Query Handling 


This section lists the behavioral requirements for a NAT device when 
processing ICMP Query packets. The following subsections discuss 
requirements specific to ICMP Query handling in detail. 


3.1. ICMP Query Mapping 


Unless explicitly overridden by local policy, a NAT device MUST 
permit ICMP Queries and their associated responses, when the Query is 
initiated from a private host to the external hosts. ICMP Query 
mapping by NAT devices is necessary for current ICMP-Query-based 
applications to work. This entails a NAT device to transparently 
forward ICMP Query packets initiated from the nodes behind NAT, and 
the responses to these Query packets in the opposite direction. As 
specified in [NAT-TRAD], this requires translating the IP header. A 
NAPT device further translates the ICMP Query Id and the associated 
checksum in the ICMP header prior to forwarding. 


NAT mapping of ICMP Query Identifiers SHOULD be external-host 
independent. Say, an internal host A sent an ICMP Query out to an 
external host B using Query Id X. And, say, the NAT assigned this an 
external mapping of Query Id X” on the NAT’s public address. If host 
A reused the Query Id X to send ICMP Queries to the same or different 
external host, the NAT device SHOULD reuse the same Query Id mapping 
(i.e., map the private host's Query Id X to Query Id X’ on NAT's 
public IP address) instead of assigning a different mapping. This is 
similar to the "endpoint independent mapping" requirement specified 
in the TCP and UDP requirement documents [BEH-UDP], [BEH-TCP]. 


Below is justification for making the endpoint-independent mapping 
for ICMP Query Id a SHOULD [RFC2119] requirement.  ICMP Ping 
[RFC1470] and ICMP traceroute [MS-TRCRT] are two most commonly known 
legacy applications built on top of ICMP Query messages. Neither of 
these applications require the ICMP Query Id to be retained across 
different sessions with external hosts. But, that may not be the 
case with future applications. In the future, when an end host 
application reuses the same Query Identifier in sessions with 
different target hosts, the end host application might require that 
the endpoint identity (i.e., the tuple of IP address and Query 
Identifier) appears the same across all its target hosts. In an IP 
network without NAT requirements, such a requirement will be valid. 
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In a world with NAT devices, the above assumption will be valid when 
NAT devices enforce endpoint mapping that is external-host 
independent. Given the dichotomy between legacy applications not 
requiring endpoint-independent mapping and future applications that 
might require it, the requirement level is kept at SHOULD [RFC2119]. 


REQ-1: Unless explicitly overridden by local policy, a NAT device 
MUST permit ICMP Queries and their associated responses, when 
the Query is initiated from a private host to the external 
hosts. 


a) NAT mapping of ICMP Query Identifiers SHOULD be external- 
host independent. 


3.2. ICMP Query Session Timeouts 


NATs maintain a mapping timeout for the ICMP Queries that traverse 
them. The mapping timeout is the time a mapping will stay active 
without packets traversing the NAT. There is great variation in the 
values used by different NATs. The ICMP Query session timeout 
requirement is necessary for current ICMP Query applications to work. 
Query response times can vary.  ICMP-Query-based applications are 
primarily request/response driven. 


Ideally, the timeout should be set to Maximum Round Trip Time 
(Maximum RTT). For the purposes of constraining the maximum RTT, the 
Maximum Segment Lifetime (MSL), defined in [RFC793], could be 
considered a guideline to set packet lifetime. Per [RFC793], MSL is 
the maximum amount of time a TCP segment can exist in a network 
before being delivered to the intended recipient. This is the 
maximum duration an IP packet can be assumed to take to reach the 
intended destination node before declaring that the packet will no 
longer be delivered. For an application initiating an ICMP Query 
message and waiting for a response for the Query, the Maximum RTT 
could in practice be constrained to be the sum total of MSL for the 
Query message and MSL for the response message. In other words, 
Maximum RTT could be constrained to no more than 2x MSL. The 
recommended value for MSL in [RFC793] is 120 seconds, even though 
several implementations set this to 60 seconds or 30 seconds. When 
MSL is 120 seconds, the Maximum RTT (2x MSL) would be 240 seconds. 


In practice, ICMP Ping [RFC1470] and ICMP traceroute [MS-TRCRT], the 
two most commonly known legacy applications built on top of ICMP 
Query messages, take less than 10 seconds to complete a round trip 
when the target node is operational on the network. 
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Setting the ICMP NAT session timeout to a very large duration (say, 
240 seconds) could potentially tie up precious NAT resources such as 
Query mappings and NAT Sessions for the whole duration. On the other 
hand, setting the timeout very low can result in premature freeing of 
NAT resources and applications failing to complete gracefully. The 
ICMP Query session timeout needs to be a balance between the two 
extremes. A 60-second timeout is a balance between the two extremes. 
An ICMP Query session timer MUST NOT expire in less than 60 seconds. 
It is RECOMMENDED that the ICMP Query session timer be made 
configurable. 


REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 
seconds. 


a) It is RECOMMENDED that the ICMP Query session timer be made 
configurable. 


4. ICMP Error Forwarding 


Many applications make use of ICMP Error messages from end hosts and 
intermediate devices to shorten application timeouts. Some 
applications will not operate correctly without the receipt of ICMP 
Error messages. The following sub-sections discuss the requirements 
a NAT device must conform to in order to ensure reliable forwarding. 


4.1. ICMP Error Payload Validation 


An ICMP Error message checksum covers the entire ICMP message, 
including the payload. When an ICMP Error packet is received, if the 
ICMP checksum fails to validate, the NAT SHOULD silently drop the 
ICMP Error packet. This is because NAT uses the embedded IP and 
transport headers for forwarding and translating the ICMP Error 
message (described in Section 4.2). When the ICMP checksum is 
invalid, the embedded IP and transport headers, which are covered by 
the ICMP checksum, are also suspect. 


[RFC1812] and [RFC1122] require a router or an end host that receives 
an IP packet with an invalid IP header checksum to silently drop the 
IP packet. As such, end hosts and routers do not generate an ICMP 
Error message in response to IP packets with invalid IP header 
checksums. For this reason, if the IP checksum of the embedded 
packet within an ICMP Error message fails to validate, the NAT SHOULD 
Silently drop the Error packet. 


When the IP packet embedded within the ICMP Error message includes IP 
options, the NAT device must not assume that the transport header of 
the embedded packet is at a fixed offset (as would be the case when 

there are no IP options associated with the packet) from the start of 
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the embedded packet. Specifically, if the embedded packet includes 
IP options, the NAT device MUST traverse past the IP options to 
locate the start of transport header for the embedded packet. 


It is possible to compute the transport checksum of the embedded 
packet within an ICMP Error message when the ICMP Error message 
contains the entire transport segment. However, ICMP Error messages 
do not contain the entire transport segment in many cases. This is 
because [ICMP] stipulates that an ICMP Error message should embed an 
IP header and only a minimum of 64 bits of the IP payload. Even 
though Section 4.3.2.3 of [RFC1812] recommends an ICMP Error 
originator include as much of the original packet as possible in the 
payload, the length of the resulting ICMP datagram cannot exceed 576 
bytes.  ICMP Error originators truncate IP packets that do not fit 
within the stipulations. 


A NAT device SHOULD NOT validate the transport checksum of the 
embedded packet within an ICMP Error message, even when it is 
possible to do so. This is because a NAT dropping an ICMP Error 
message due to an invalid transport checksum will make it harder for 
end hosts to receive error reporting for certain types of corruption. 
End-to-end validation of ICMP Error messages is best left to end 
hosts. Many newer revision end host TCP/IP stacks implement the 
improvements in [TCP-SOFT] and do not accept ICMP Error messages with 
a mismatched IP or TCP checksum in the embedded packet, if the 
embedded datagram contains a full IP packet and the TCP checksum can 
be calculated. 


In the case that the ICMP Error payload includes ICMP extensions 
[ICMP-EXT], the NAT device MUST exclude the optional zero-padding and 
the ICMP extensions when evaluating transport checksum for the 
embedded packet. Readers are urged to refer to [ICMP-EXT] for 
information on identifying the presence of ICMP extensions in an ICMP 
message. 


REQ-3: When an ICMP Error packet is received, if the ICMP checksum 
fails to validate, the NAT SHOULD silently drop the ICMP Error 
packet. If the ICMP checksum is valid, do the following: 


a) If the IP checksum of the embedded packet fails to 
validate, the NAT SHOULD silently drop the Error packet; 
and 


b) If the embedded packet includes IP options, the NAT device 


MUST traverse past the IP options to locate the start of 
the transport header for the embedded packet; and 
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c) The NAT device SHOULD NOT validate the transport checksum 
of the embedded packet within an ICMP Error message, even 
when it is possible to do so; and 


d) If the ICMP Error payload contains ICMP extensions 
[ICMP-EXT], the NAT device MUST exclude the optional zero- 
padding and the ICMP extensions when evaluating transport 
checksum for the embedded packet. 


4.2. ICMP Error Packet Translation 


Section 4.3 of [NAT-TRAD] describes the fields of an ICMP Error 
message that a NAT device translates. In this section, we describe 
the requirements a NAT device must conform to while performing the 
translations. Requirements identified in this section are necessary 
for the current applications to work correctly. 


Consider the following scenario in Figure 1. Say, NAT-xy is a NAT 
device connecting hosts in private and external networks. Router-x 
and Host-x are in the external network. Router-y and Host-y are in 
the private network. The subnets in the external network are 
routable from the private as well as the external domains. By 
contrast, the subnets in the private network are only routable within 
the private domain. When Host-y initiated a session to Host-x, let 
us say that the NAT device mapped the endpoint on Host-y into Host-y' 
in the external network. The following subsections describe the 
processing of ICMP Error messages on the NAT device(NAT-xy) when the 
NAT device receives an ICMP Error message in response to a packet 
pertaining to this session. 
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— ———— Oe (——— —— qp——————————————————— 
4------------- + 
Router-x 
4R------------- + 


External Network | 


| 
| | (Host-y', Host-x) 


4------------- * 
NAT-xy | 
4------------- * 
Private Network 
——————————————— 4+--------—-—-— -— -—+---- 
$ + 
Router-y | 
$ + 
——————————————— a 


Figure 1. A Session from a Private Host Traversing a NAT Device 


24525 1s ICMP Error Packet Received from the External Realm 


Say, a packet from Host-y to Host-x triggered an ICMP Error message 
from one of Router-x or Host-x (both of which are in the external 
domain). Such an ICMP Error packet will have one of Router-x or 
Host-x as the source IP address and Host-y' as the destination IP 
address as described in Figure 2 below. 
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Host-x 
dual, us fen eut dui had gu Qs Vid. ni Denn ai iq id qp——————————————————— 
4------------- * 
Router-x 
4------------- * 
External Network 
yon us md qnd A verd mi us led wy EA a 


v 
+------------- + 
NAT-xy | 
+------------- + 
Private Network | 
recur RS a - 
4R------------- * 
Router-y | 
4+------------- + 
SSS SS ee ee +--+- 
Host-y 
Figure 2. ICMP Error Packet Received from External Network 


When the NAT device receives the ICMP Error packet, the NAT device 
uses the packet embedded within the ICMP Error message (i.e., the IP 
packet from Host-y” to Host-x) to look up the NAT Session to which 
the embedded packet belongs. If the NAT device does not have an 
active mapping for the embedded packet, the NAT SHOULD silently drop 
the ICMP Error packet. Otherwise, the NAT device MUST use the 
matching NAT Session to translate the embedded packet; that is, 
translate the source IP address of the embedded packet (e.g., Host-y' 
-» Host-y) and transport headers. 


The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. 
NATs are encouraged to support ICMP extension objects. At the time 
of this writing, the authors are not aware of any standard ICMP 
extension objects containing realm-specific information. 


The NAT device MUST also use the matching NAT Session to translate 
the destination IP address in the outer IP header. In the outer 
header, the source IP address will remain unchanged because the 
originator of the ICMP Error message (Host-x or Router-x) is in an 
external domain and is routable from the private domain. 
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REQ-4: If a NAT device receives an ICMP Error packet from an external 
realm, and the NAT device does not have an active mapping for 
the embedded payload, the NAT SHOULD silently drop the ICMP 
Error packet. If the NAT has active mapping for the embedded 
payload, then the NAT MUST do the following prior to 
forwarding the packet, unless explicitly overridden by local 
policy: 


a) Revert the IP and transport headers of the embedded IP 
packet to their original form, using the matching mapping; 
and 


b) Leave the ICMP Error type and code unchanged; and 


c) Modify the destination IP address of the outer IP header to 
be the same as the source IP address of the embedded packet 
after translation. 


a4 5 FP, ICMP Error Packet Received from the Private Realm 


Now, say, a packet from Host-x to Host-y triggered an ICMP Error 
message from one of Router-y or Host-y (both of which are in the 
private domain). Such an ICMP Error packet will have one of Router-y 
or Host-y as the source IP address and Host-x as the destination IP 
address as specified in Figure 3 below. 
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Host-x 
dual, us fen eut dui had gu Qs Vid. ni Denn ai iq id qp——————————————————— 
4------------- * 
Router-x 
4------------- * 
External Network 
ye us d qn d vay ioni Epp uut verd Emi us led wy mf Eos Feud E a 
4+------------- + 
NAT-xy | 
4+------------- + 


Private Network 


SS SS SS SS SS te a - 
4------------- + 
Router-y | 
4R------------- * 
—Á———— Á—— et a 
Host-y 
Figure 3. ICMP Error Packet Received from Private Network 


When the NAT device receives the ICMP Error packet, the NAT device 
MUST use the packet embedded within the ICMP Error message (i.e., the 
IP packet from Host-x to Host-y) to look up the NAT Session to which 
the embedded packet belongs. If the NAT device does not have an 
active mapping for the embedded packet, the NAT SHOULD silently drop 
the ICMP Error packet. Otherwise, the NAT device MUST use the 
matching NAT Session to translate the embedded packet. 


The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. 
NATs are encouraged to support ICMP extension objects. At the time 
of this writing, the authors are not aware of any standard ICMP 
extension objects containing realm-specific information. 


In the outer header, the destination IP address will remain 
unchanged, as the IP address for Host-x is already in the external 
domain. If the ICMP Error message is generated by Host-y, the NAT 
device must simply use the NAT Session to translate the source IP 
address Host-y to Host-y’. If the ICMP Error message is originated 
by the intermediate node Router-y, translation of the source IP 
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address varies depending on whether the Basic NAT or NAPT function 
[NAT-TRAD] is enforced by the NAT device. A NAT device enforcing the 
Basic NAT function has a pool of public IP addresses and enforces 
address mapping (which is different from the endpoint mapping 
enforced by NAPT) when a private node initiates an outgoing session 
via the NAT device. So, if the NAT device has active mapping for the 
IP address of the intermediate node Router-y, the NAT device MUST 
translate the source IP address of the ICMP Error packet with the 
public IP address in the mapping. In all other cases, the NAT device 
MUST simply use its own IP address in the external domain to 
translate the source IP address. 


REQ-5: If a NAT device receives an ICMP Error packet from the private 
realm, and the NAT does not have an active mapping for the 
embedded payload, the NAT SHOULD silently drop the ICMP Error 
packet. If the NAT has active mapping for the embedded 
payload, then the NAT MUST do the following prior to 
forwarding the packet, unless explicitly overridden by local 
policy: 


a) Revert the IP and transport headers of the embedded IP 
packet to their original form, using the matching mapping; 


and 


b) Leave the ICMP Error type and code unchanged; and 


c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and 
the NAT has active mapping for the IP address that sent the 
ICMP Error, translate the source IP address of the ICMP 
Error packet with the public IP address in the mapping. In 
all other cases, translate the source IP address of the 
ICMP Error packet with its own public IP address. 


4.3. NAT Sessions Pertaining to ICMP Error Payload 


While processing an ICMP Error packet pertaining to an ICMP Query or 
Query response message, a NAT device MUST NOT refresh or delete the 
NAT Session that pertains to the embedded payload within the ICMP 
Error packet. This is in spite of the fact that the NAT device uses 
the NAT Session to translate the embedded payload. This ensures that 
the NAT Session will not be modified if someone is able to spoof ICMP 
Error messages for the session. [ICMP-ATK] lists a number of 
potential ICMP attacks that may be attempted by malicious users on 
the network. This requirement is necessary for current applications 
to work correctly. 
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REO-6: While processing an ICMP Error packet pertaining to an ICMP 
Query or Query response message, a NAT device MUST NOT refresh 
or delete the NAT Session that pertains to the embedded 
payload within the ICMP Error packet. 


5. Hairpinning Support for ICMP Packets 


[BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and 
TCP sessions, respectively, on NAT devices. A NAT device needs to 
support hairpinning for ICMP Query sessions as well. Specifically, 
NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal 
of hairpinned ICMP Query sessions. Say, for example, individual 
private hosts register their NAT assigned external IP address with a 
rendezvous server. Other hosts that wish to initiate ICMP Query 
sessions to the registered hosts might do so using the public address 
registered with the rendezvous server. For this reason, Basic NAT 
devices are required to support the traversal of hairpinned ICMP 
Query sessions. This requirement is necessary for current 
applications to work correctly. 


Packets belonging to any of the hairpinned sessions could, in turn, 
trigger ICMP Error messages directed to the source of hairpinned IP 
packets. Such hairpinned ICMP Error messages will traverse the NAT 
devices en route. All NAT devices (i.e., Basic NAT as well as NAPT 
devices) MUST support the traversal of hairpinned ICMP Error 
messages. Specifically, the NAT device must translate not only the 
embedded hairpinned packet, but also the outer IP header that is 
hairpinned. This requirement is necessary for current applications 
to work correctly. 


A hairpinned ICMP Error message is received from a node in a private 
network. As such, the ICMP Error processing requirement specified in 
Req-5 is applicable in its entirety in processing the ICMP Error 
message. In addition, the NAT device MUST translate the destination 
IP address of the outer IP header to be same as the source IP address 
of the embedded IP packet after the translation. 


REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the 
traversal of hairpinned ICMP Query sessions. All NAT devices 
(i.e., Basic NAT as well as NAPT devices) MUST support the 
traversal of hairpinned ICMP Error messages: 


a) When forwarding a hairpinned ICMP Error message, the NAT 
device MUST translate the destination IP address of the 
outer IP header to be same as the source IP address of the 
embedded IP packet after the translation. 
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6. 


Rejection of Outbound Flows Disallowed by NAT 


A NAT device typically permits all outbound sessions. However, a NAT 
device may disallow some outbound sessions due to resource 
constraints or administration considerations. For example, a NAT 
device may not permit the first packet of a new outbound session if 
the NAT device is out of resources (out of addresses or TCP/UDP 
ports, or NAT Session resources) to set up a state for the session, 
or, if the specific session is administratively restricted by the NAT 
device. 


When a NAT device is unable to establish a NAT Session for a new 
transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 
constraints or administrative restrictions, the NAT device SHOULD 
send an ICMP destination unreachable message, with a code of 13 
(Communication administratively prohibited) to the sender, and drop 
the original packet. This requirement is meant primarily for future 
use. Current applications do not require this for them to work 
correctly. The justification for using ICMP code 13 in the ICMP 
Error message is as follows: Section 5.2.7.1 of [RFC1812] recommends 
routers use ICMP code 13 (Communication administratively prohibited) 
when they administratively filter packets. ICMP code 13 is a soft 
error and is on par with other soft error codes generated in response 
to transient events such as "network unreachable" (ICMP type=3, 
code=0). 


Some NAT designers opt to never reject an outbound flow. When a NAT 
runs short of resources, they prefer to steal a resource from an 
existing NAT Session rather than reject the outbound flow. Such a 
design choice may appear conformant to REQ-8 below. However, the 
design choice is in violation of the spirit of both REQ-8 and REQ-2. 
Such a design choice is strongly discouraged. 


REQ-8: When a NAT device is unable to establish a NAT Session for a 
new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 
constraints or administrative restrictions, the NAT device SHOULD 
send an ICMP destination unreachable message, with a code of 13 
(Communication administratively prohibited) to the sender, and drop 
the original packet. 


Conformance to RFC 1812 


This document specifies NATs to have a behavior that is consistent 
with the way routers handle ICMP messages, as specified in Section 
4.3 of [RFC1812]. However, since the publication of [RFC1812], some 
of its requirements are no longer best current practices. Thus, the 
following requirements are derived from [RFC1812] and apply to NATs 
compliant with this specification: 
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REO-9: A NAT device MAY implement a policy control that prevents ICMP 


REQ-10: 


Srisuresh, 


Unless overridden by REQ-9's policy, 
support ICMP messages as below, some conforming to Section 


messages being generated toward certain interface(s). 
Implementation of such a policy control overrides the MUSTs 
and SHOULDs in REQ-10. 


4.3 of [RFC1812] and some superseding the requirements of 
Section 4.3 of [RFC1812]: 


MUST support: 


a NAT device needs to 


1. Destination Unreachable Message, as described in Section 


7.1 of this document. 


2. Time Exceeded Message, as described in Section 7.2 of 


this document. 
3. Echo Request/Reply Messages, as described in REQ-1. 
MAY support: 


1. Redirect Message, as described in Section 4.3.3.2 of 
[RFC1812]. 


2. Timestamp and Timestamp Reply Messages, as described 
Section 4.3.3.8 of [RFC1812]. 


3. Source Route Options, as described in Section 7.3 of 
this document. 


4. Address Mask Request/Reply Message, as described in 
Section 7.4 of this document. 


5. Parameter Problem Message, as described in Section 7. 


of this document. 


6. Router Advertisement and Solicitations, as described 
Section 7.6 of this document. 


SHOULD NOT support: 


1. Source Quench Message, as described in Section 4.3.3. 


of [RFC1812]. 


2. Information Request/reply, as described in Section 
4.3.3.7 of [RFC1812]. 
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In addition, a NAT device is RECOMMENDED to conform to the 
following implementation considerations: 


d. DS Field Usage, as described in Section 7.7 of this 
document. 


e. When Not to Send ICMP Errors, as described in Section 
4.3.2.7 of [RFC1812]. 


f. Rate Limiting, as described in Section 4.3.2.8 of 
[RFC1812]. 


7.1. IP Packet Fragmentation 


Many networking applications (which include TCP- as well as UDP-based 
applications) depend on ICMP Error messages from the network to 
perform end-to-end path MTU discovery [PMTU]. Once the path MTU is 
discovered, an application that chooses to avoid fragmentation may do 
so by originating IP packets that fit within the path MTU en route 
and setting the DF (Don’t Fragment) bit in the IP header, so the 
intermediate nodes en route do not fragment the IP packets. The 
following sub-sections discuss the need for NAT devices to honor the 
DF bit in the IP header and be able to generate "Packet Too Big" ICMP 
Error message when they cannot forward the IP packet without 
fragmentation. Also discussed is the need to seamlessly forward ICMP 
Error messages generated by other intermediate devices. 


7.1.1. Generating "Packet Too Big" ICMP Error Message 


When a router is unable to forward a datagram because it exceeds the 
MTU of the next-hop network and its Don’t Fragment (DF) bit is set, 
the router is required by [RFC1812] to return an ICMP Destination 
Unreachable message to the source of the datagram, with the code 
indicating "fragmentation needed and DF set". Further, [PMTU] states 
that the router MUST include the MTU of that next-hop network in the 
low-order 16 bits of the ICMP header field that is labeled "unused" 
in the ICMP specification [ICMP]. 


A NAT device MUST honor the DF bit in the IP header of the packets 
that transit the device. The NAT device may not be able to forward 
an IP packet without fragmentation if the MTU on the forwarding 
interface of the NAT device is not adequate for the IP packet. If 
the DF bit is set on a transit IP packet and the NAT device cannot 
forward the packet without fragmentation, the NAT device MUST send a 
"Packet Too Big" ICMP message (ICMP type 3, code 4) with the next-hop 
MTU back to the sender and drop the original IP packet. The sender 
will usually resend after taking the appropriate corrective action. 


Srisuresh, et al. Best Current Practice [Page 19] 


RFC 5508 NAT Behavioral Requirements for ICMP April 2009 


If the DF bit is not set and the MTU on the forwarding interface of 
the NAT device mandates fragmentation, the NAT device MUST fragment 
the packet and forward the fragments [RFC1812]. 


7.1.2. Forwarding "Packet Too Big" ICMP Error Message 


This is the flip side of the argument for the above section. By 
virtue of the address translation NAT performs, NAT may end up being 
the recipient of "Packet Too Big" messages. 


When the NAT device is the recipient of a "Packet Too Big" ICMP 
message from the network, the NAT device MUST forward the ICMP 
message back to the intended recipient, pursuant to the previously 
stated requirements (REQ-3, REQ-4, and REQ-5). 


7.2. Time Exceeded Message 


A NAT device MUST generate a "Time Exceeded" ICMP Error message when 
it discards a packet due to an expired Time to Live (TTL) field. A 
NAT device MAY have a per-interface option to disable origination of 
these messages on that interface, but that option MUST default to 
allowing the messages to be originated. 


When a NAT device conforms to the above requirement, it ensures that 
legacy applications such as Traceroute [RFC1470], [MS-TRCRT], which 
depend upon the "Time Exceeded" ICMP Error message, will continue to 
operate even as NAT devices are en route. 


7.3. Source Route Options 


A NAT device MAY support modifying IP addresses in the source route 
option so the IP addresses in the source route option are realm 
relevant. If a NAT device does not support forwarding packets with 
the source route option, the NAT device SHOULD NOT forward outbound 
ICMP messages that contain the source route option in the outer or 
inner IP header. This is because such messages could reveal private 
IP addresses to the external realm. 


7.4. Address Mask Request/Reply Messages 


Section 4.3.3.9 of [RFC1812] says an IP router MUST implement support 
for receiving ICMP Address Mask Request messages and responding with 
ICMP Address Mask Reply messages. However, several years (more than 
13 years at the time of this document) have elapsed since the text in 
RFC 1812 was written. In the intervening time, DHCP [DHCP] has 

replaced the use of address mask request/reply. At the current time, 
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there is rarely any host that does not meet host requirements 
[RFC1122] and needs a NAT device to support address mask 
request/reply. 


For this reason, a NAT device is not required to support this ICMP 
message. 


A NAT device MAY support address mask request/reply messages. 
7.5. Parameter Problem Message 


Section 4.3.3.5 of [RFC1812] says an IP router MUST generate a 
Parameter Problem message for any error not specifically covered by 
another ICMP message. However, this message is rarely used in 
practice in networks where IPv4 NATs are deployed. 


For this reason, a NAT device is not required to support this ICMP 
message. 


A NAT device MAY support parameter problem messages. 
7.6. Router Advertisement and Solicitations 


Section 4.3.3.10 of [RFC1812] says an IP router MUST support the 
router part of the ICMP Router Discovery Protocol on all connected 
networks on which the router supports either IP multicast or IP 
broadcast addressing. However, this message is rarely used in 
practice in networks where IPv4 NATs are deployed. 


For this reason, a NAT device is not required to support this ICMP 
message. 


A NAT device MAY support Router Advertisement and Solicitations. 
7.7. DS Field Usage 


[RFC1812] refers to the Type of Service (TOS) octet in the IP header, 
which contains the TOS and IP precedence fields. However, the TOS 
and IP precedence fields are no longer in use today. [RFC2474] 
renamed the TOS octet as the DS field and defined diffserv classes 
within the DS field. 


When generating an ICMP message, a NAT device SHOULD copy the 
diffserv class of the message that causes the sending of the ICMP 
error message. A NAT device MAY allow configuration of the diffserv 
class to be used for the different types of ICMP messages. 


Srisuresh, et al. Best Current Practice [Page 21] 


RFC 5508 NAT Behavioral Requirements for ICMP April 2009 


8. 


Non-QueryError ICMP Messages 


In the preceding sections, ICMP requirements were identified for NAT 
devices, with a primary focus on ICMP Query and ICMP Error messages, 
as defined in the Terminology Section (see Section 2). This document 
provides no guidance on the handling of Non-QueryError ICMP messages 
by the NAT devices. A NAT MAY drop or appropriately handle Non- 
QueryError ICMP messages. 


REQ-11: A NAT MAY drop or appropriately handle Non-QueryError 
ICMP messages. The semantics of Non-QueryError ICMP messages 
is defined in Section 2. 


Summary of Requirements 
Below is a summary of all the requirements. 
REQ-1: Unless explicitly overridden by local policy, a NAT device 
MUST permit ICMP Queries and their associated responses, when 


the Query is initiated from a private host to the external 
hosts. 


a) NAT mapping of ICMP Query Identifiers SHOULD be external 
host independent. 


REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 
seconds. 


a) It is RECOMMENDED that the ICMP Query session timer be made 
configurable. 


REQ-3: When an ICMP Error packet is received, if the ICMP checksum 
fails to validate, the NAT SHOULD silently drop the ICMP Error 
packet. If the ICMP checksum is valid, do the following: 


a) If the IP checksum of the embedded packet fails to 
validate, the NAT SHOULD silently drop the Error packet; 
and 


b) If the embedded packet includes IP options, the NAT device 
MUST traverse past the IP options to locate the start of 
the transport header for the embedded packet; and 


c) The NAT device SHOULD NOT validate the transport checksum 
of the embedded packet within an ICMP Error message, even 
when it is possible to do so; and 
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d) If the ICMP Error payload contains ICMP extensions 
[ICMP-EXT], the NAT device MUST exclude the optional zero- 
padding and the ICMP extensions when evaluating transport 
checksum for the embedded packet. 


If a NAT device receives an ICMP Error packet from an external 
realm, and the NAT device does not have an active mapping for 
the embedded payload, the NAT SHOULD silently drop the ICMP 
Error packet. If the NAT has active mapping for the embedded 
payload, then the NAT MUST do the following prior to 
forwarding the packet, unless explicitly overridden by local 
policy: 


a) Revert the IP and transport headers of the embedded IP 
packet to their original form, using the matching mapping; 
and 


b) Leave the ICMP Error type and code unchanged; and 


c) Modify the destination IP address of the outer IP header to 
be same as the source IP address of the embedded packet 
after translation. 


If a NAT device receives an ICMP Error packet from the private 
realm, and the NAT does not have an active mapping for the 
embedded payload, the NAT SHOULD silently drop the ICMP Error 
packet. If the NAT has active mapping for the embedded 
payload, then the NAT MUST do the following prior to 
forwarding the packet, unless explicitly overridden by local 
policy. 


a) Revert the IP and transport headers of the embedded IP 
packet to their original form, using the matching mapping; 
and 


b) Leave the ICMP Error type and code unchanged; and 


c) If the NAT enforces Basic NAT function [NAT-TRAD], and the 
NAT has active mapping for the IP address that sent the 
ICMP Error, translate the source IP address of the ICMP 
Error packet with the public IP address in the mapping. In 
all other cases, translate the source IP address of the 
ICMP Error packet with its own public IP address. 


While processing an ICMP Error packet pertaining to an ICMP 
Query or Query response message, a NAT device MUST NOT refresh 
or delete the NAT Session that pertains to the embedded 
payload within the ICMP Error packet. 
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NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 
traversal of hairpinned ICMP Query sessions. All NAT devices 
(i.e., Basic NAT as well as NAPT devices) MUST support the 
traversal of hairpinned ICMP Error messages. 


a) When forwarding a hairpinned ICMP Error message, the NAT 
device MUST translate the destination IP address of the 
outer IP header to be same as the source IP address of the 
embedded IP packet after the translation. 


When a NAT device is unable to establish a NAT Session for a 
new transport-layer (TCP, UDP, ICMP, etc.) flow due to 
resource constraints or administrative restrictions, the NAT 
device SHOULD send an ICMP destination unreachable message, 
with a code of 13 (Communication administratively prohibited) 
to the sender, and drop the original packet. 


A NAT device MAY implement a policy control that prevents ICMP 
messages being generated toward certain interface(s). 
Implementation of such a policy control overrides the MUSTs 
and SHOULDs in REQ-10. 
Unless overridden by REQ-9's policy, a NAT device needs to 
support ICMP messages as below, some conforming to Section 
4.3 of [RFC1812] and some superseding the requirements of 
Section 4.3 of [RFC1812]: 
a. MUST support: 


1. Destination Unreachable Message, as described in Section 
7.1 of this document. 


2. Time Exceeded Message, as described in Section 7.2 of 
this document. 


3. Echo Request/Reply Messages, as described in REQ-1. 
b. MAY support: 


1. Redirect Message, as described in Section 4.3.3.2 of 
[RFC1812]. 


2. Timestamp and Timestamp Reply Messages, as described in 
Section 4.3.3.8 of [RFC1812]. 


3. Source Route Options, as described in Section 7.3 of 
this document. 
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4. Address Mask Request/Reply Message, as described in 
Section 7.4 of this document. 


5. Parameter Problem Message, as described in Section 7.5 
of this document. 


6. Router Advertisement and Solicitations, as described in 
Section 7.6 of this document. 


C. SHOULD NOT support: 


1. Source Quench Message, as described in Section 4.3.3.3 
of [RFC1812]. 


2. Information Request/reply, as described in Section 
4.3.3.7 of [RFC1812]. 


In addition, a NAT device is RECOMMENDED to conform to the 
following implementation considerations: 


d. DS Field Usage, as described in Section 7.7 of this 
document. 


e. When Not to Send ICMP Errors, as described in Section 
4.3.2.7 of [RFC1812]. 


f. Rate Limiting, as described in Section 4.3.2.8 of 
[RFC1812]. 


REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP 
messages. The semantics of Non-QueryError ICMP messages is 
defined in Section 2. 


10. Security Considerations 


This document does not introduce any new security concerns related to 
ICMP message handling in the NAT devices. However, the requirements 
in the document do mitigate some security concerns known to exist 
with ICMP messages. 


[ICMP-ATK] lists a number of ICMP attacks that can be directed 
against end host TCP stacks. For example, a rogue entity could 
bombard the NAT device with a large number of ICMP Errors. If the 
NAT device did not validate the legitimacy of the ICMP Error packets, 
the ICMP Errors would be forwarded directly to the end nodes. End 
hosts not capable of defending themselves against such bogus ICMP 
Error attacks could be adversely impacted by such attacks.  Req-3 
recommends validating the ICMP checksum and the IP checksum of the 
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Ts 


embedded payload prior to forwarding. These checksum validations by 
themselves do not protect end hosts from attacks. However, checksum 
validation mitigates end hosts from malformed ICMP Error attacks. 
Req-4 and Req-5 further mandate that when a NAT device does not find 
a mapping selection for the embedded payload, the NAT should drop the 
ICMP Error packets, without forwarding. 


A rogue source could also try to send bogus ICMP Error messages for 
the active NAT sessions, with intent to destroy the sessions.  Req-6 
averts such an attack by ensuring that an ICMP Error message does not 
affect the state of a session on the NAT device. 


Req-8 recommends a NAT device sending an ICMP Error message when the 
NAT device is unable to create a NAT session due to lack of 
resources. Some administrators may choose not to have the NAT device 
send an ICMP Error message, as doing so could confirm to a malicious 
attacker that the attack has succeeded. For this reason, sending of 
the specific ICMP Error message stated in REQ-8 is left to the 
discretion of the NAT device administrator. 


Unfortunately, ICMP messages are sometimes blocked at network 
boundaries due to local security policy. Thus, some of the 
requirements in this document allow local policy to override the 
recommendations of this document. Blocking such ICMP messages is 
known to break some protocol features (most notably path MTU 
Discovery) and some applications (e.g., ping, traceroute), and such 
blocking is NOT RECOMMENDED. 
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